With rise in deployment of Long term Evolution (LTE) and LTE advanced (LTE-A), small cells using low power nodes such as a Pico cell and a Femto cell are considered promising to cope with mobile traffic explosion. A small cell using a low power node, which has transmission power (Tx) lower than macro node and Base Station (BS) classes, is preferred for hotspot deployments in indoor and outdoor scenarios resulting in enhanced performance.
The small cell enhancement for Evolved Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (E-UTRAN) and E-UTRA focuses on additional functionalities for enhanced performance in hotspot areas for indoor and outdoor using the low power nodes.
The 3rd Generation Partnership Project (3GPP) is considering use of potential higher layer technologies for enhanced support of small cell deployments in Evolved (Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (E-UTRA) and E-Evolved UMTS Terrestrial Radio Access Network (UTRAN) to fulfill the deployment scenarios and the requirements specified in TR 36.932.
3GPP is considering a deployment scenario, in which different frequency bands are separately assigned to macro layer and small cell layer, respectively. Small cell enhancement is expected to support significantly increased user throughput for both downlink and uplink with main focus on typical user throughput, considering a reasonable system complexity. Small cell enhancement is expected to target the capacity per unit area (such as in bps/km2) to be as high as possible, for a given user and small cell distribution, typical traffic types and considering a reasonable system complexity. The small cell enhancements are also expected to consider the impact of the actual backhaul delays and provide solutions with the aim of improved system performance. Other aspects, for example service quality of Voice over Long Term Evolution (LTE) (VoLTE), such as Mean Opinion Score (MOS) and delay or jitter impacts on services, such as video streaming, video calls and so forth, could also be addressed later.
In LTE Release-10 carrier aggregation, all the component carriers involved in carrier aggregation is handled at the same evolved NodeB (eNB) (co-located) and the component carriers are from the same frequency band i.e. intra-band carrier aggregation. In LTE Release-11 specification supports inter-band carrier aggregation where the component carriers are from different frequency bands. In the inter-band carrier aggregation scenario the component carrier (F1) from a lower frequency band can provide coverage and mobility whereas the other component carrier (F2) from a higher frequency band can provide high throughput to the User Equipment (UE). The inter-band carrier aggregation could be non-co-located, where the UE is carrier aggregated with at least one first serving frequency by a Master eNB (MeNB) and at least one second serving frequency served by a Secondary eNB (SeNB). When carrier aggregation between at least one cell controlled by two geographically separated eNBs is envisioned then it is called as inter-eNB carrier aggregation and the UE is said to be configured with dual connectivity mode of operation. In such a scenario, dual connectivity is envisioned such that the UE maintains physical links with at least one cell controlled by two geographically separated eNBs. The UE maintains dual connectivity both in downlink and uplink or only downlink. In uplink the dual connectivity towards the MeNB and the SeNB could be simultaneous or could be time multiplexed.
In the so-called dual connectivity mode of operation, the UE consumes radio resources provided by two different network nodes, namely MeNB associated with at least one first serving frequency and SeNB associated with at least one second serving frequency, connected via a non-ideal backhaul interface, such as X2 interface. The MeNB is the eNB that hosts the Radio Resource Control (RRC) layer and a single S1-MME termination point exists for a UE configured with dual connectivity mode of operation between the Mobile Management Entity (MME) and the E-UTRAN. The MeNB, therefore, acts as a mobility anchor towards the core network (CN). The E-UTRAN architecture and related functions to support Dual Connectivity for E-UTRAN is further described in TS 36.300.
In existing security mechanisms for single connectivity or UE supporting Release-10 or Release-11 carrier aggregation, authentication and authorization are performed using the authentication and key agreement procedure (AKA) defined for the evolved Universal Terrestrial Radio Access Network (E-UTRAN) in the LTE Networks. An initial security key is derived by the Mobility Management Entity (MME) in the core network and sent to a serving or source eNB of the UE. During an inter-eNB (S1 or X2-intiated) handover, the serving eNB derives the security key for a target eNB, using a base security key (if an interface such as an X2 interface exists between the serving eNB and the target eNB), to which the UE is handed over due to mobility. The security key provided by the serving eNB is used for deriving further keys in the target eNB, which are used for user plane data protection (same like serving eNB, UE derives the security key and further keys like target eNB).
During a handover (HO), using vertical key derivation, that is, the unused next hop (NH) parameters can be used for deriving the base security key at the source eNB (when S1 interface is involved in HO procedure). For dual connectivity, the existing procedure using vertical key derivation, a new security key associated with the secondary eNB (SeNB) for the UE can be derived at the Master eNB (MeNB) using unused Next Hop (NH) parameters. However, the unused NH parameters may not be always available at the MeNB to derive the security key associated with SeNB using vertical key derivation. In existing security mechanism during HO an existing security key associated with the source eNB can be used for deriving the base security key. For dual connectivity, this principle can be extended such that the existing security key of the MeNB can be used as for deriving the security key for the SeNB. The use of the MeNB security key for deriving the security key of SeNB for securing the communication between the SeNB and the UE may not provide adequate key separation and also possible key stream repetition issue, resulting in security compromise.
Further, if the MeNB derives security key for the SeNB using an existing security key, then the key repetition will occur. For example, if each time the same SeNB is removed and added again for supporting dual connectivity, the security key generated may be repeated. Further key repetition may also occur if the first SeNB is removed and another different second SeNB is added, but the first SeNB and second SeNB operate on the same frequency and have the same physical cell identity (PCI). Another scenario for key repetition occurrence is when the user plane data handled by the data radio bearer (DRB) established on the SeNB experience PDCP COUNT wrap around (that is, when same PDCP Count value with same DRB-ID and security key are used again (more than once), it is possible to derive the key stream or message details). Therefore, key stream repetition is highly possible when the existing security mechanism defined in TS 33.401 is used for dual connectivity and leads to exposing the user plane to security attacks, which needs to be avoided.
In addition to key repetition, the security capabilities and/or local configuration of the SeNB may be different from the MeNB. Hence, the UE configured with dual connectivity may need to use different cryptographic algorithms for communicating with the SeNB. The establishment of security context between the SeNB and the UE requires knowledge of the security algorithms supported and selected by the MeNB.
When there is no restriction to add only one SCell in the SeNB at a time, that is, it is allowed to add more than one SCell in the SeNB at initial configuration of the SeNB, then using the existing HO security mechanism for Dual connectivity, the MeNB should know the PCI and operating downlink frequency (EARFCN-DL) of one of the SCell within the SeNB to be used to derive the security key for the SeNB.
When the PDCP count of any PDCP entity handling the DRB in MeNB is about to wrap around then the MeNB could initiate intra-cell handover (i.e., handover to the same MeNB cell) to refresh the MeNB key, then the MeNB would have to release all the SCells in the SeNB at the same time in order to ensure that security key of SeNB is also updated (based on refreshed MeNB key). When the security key of the MeNB is updated while the SeNB continues to use existing security key that was derived from previous security key of the MeNB, then this may result in security compromise and, hence, it is not a good security practice (to use secondary keys derived from primary key which is invalidated). When the PDCP count of any PDCP entity handling the DRB in the SeNB is about to wrap around, then key repetition occurrence is possible when the user plane data handled by the data radio bearer (DRB) established on the SeNB experience PDCP COUNT wrap around (that is same PDCP Count value with same DRB-ID and security key are used again (more than once)).
Limitations and disadvantages exist in the operation and management of security mechanism such as countercheck procedure execution for DRB established in the SeNB for a UE configured with dual connectivity mode of operation that can lead to a potential compromise in security. Existing countercheck procedure does not address the issue of intruder detection in dual connectivity, as the SeNB does not have direct RRC signaling connection with the UE. There needs to be a method to check the PDCP counter associated with the SeNB, for whether an packet injection attack is mounted and also possibly flag the DRB-IDs with the indication indicating which node is responsible for handling the DRB and providing the UE the means to identity the correct DRB context used in the MeNB or SeNB.
In legacy LTE systems (namely, Release 8 to Release 11), the countercheck procedure is specified in 3GPP specification TS 36.331 (section 5.3.6) for detecting packet injection attack, where the RRC procedure is kind of audit where eNB checks if the PDCP COUNT provided by the UE for the established DRBs match with the values sent by the eNB in the request message of the procedure. If such an intruder attack is detected, then the network can decide to release the RRC connection immediately and can initiate other procedure like informing network node about the attack. For Release-10 carrier aggregation (CA), the primary cell (PCell) of the UE initiates the countercheck procedure for the DRB established on the SCell(s). This principle cannot be applied for dual connectivity where the RRC layer sits in the MeNB and there is no context or information about the PDCP entity in the SeNB available with the MeNB.
Compared to Release-10 CA, the extension of countercheck procedure for dual connectivity requires new signaling support on the X2 interface and also in the RRC signaling between the UE and the MeNB.